Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7, а также функциональности нового механизма динамического распределения нагрузки VMware DRS 2.0. Среди новых возможностей DRS мы упоминали про функции Assignable Hardware, которые позволяют назначить профили устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU для первоначального размещения виртуальных машин в кластере.

Сегодня мы поговорим об этой технологии в целом. Ранее виртуальные машины, использовавшие технологии DirectPath I/O или vGPU, привязывались к физическому адресу устройства, который включал в себя адрес расположения устройства на конкретной шине PCIe конкретного хоста ESXi. Это делало невозможным использование такой ВМ на других серверах кластера, что, конечно же, делало невозможным и работу технологий HA и DRS, которые являются критически важными в современных датацентрах.

Таким образом, технология Assignable Hardware позволяет отделить виртуальную машину от конкретного устройства и дать ей возможность быть запущенной на другом хосте ESXi с таким же устройством (или даже другим, но поддерживающим определенный набор функций).

Теперь при настройке виртуальной машины у вас есть выбор одного из следующих вариантов для устройства PCIe:

• DirectPath I/O (legacy-режим, без интеграции с HA и DRS)
• Dynamic DirectPath I/O
• NVIDIA vGPU

После того, как вы выберете нужный профиль оборудования, механизм DRS сможет разместить машину на хосте ESXi с поддержкой нужных функций для ВМ.

На скриншоте выше, во второй опции Select Hardware, также есть лейбл "GPGPU example" - это возможность задать определенным устройствам метки таким образом, чтобы при выборе размещения ВМ использовались только устройства хостов с данными метками (при этом модели устройств могут отличаться, например, NVIDIA T4 GPU и RTX6000 GPU). Либо можно выбрать вариант использования только идентичных устройств.

Назначить метку можно во время конфигурации PCIe-устройств. В гифке ниже показано, как это делается:

При использовании NVIDIA vGPU для виртуальной машины выделяется только часть устройства. Поддержка горячей миграции vMotion для машин, использующих vGPU, уже была анонсирована в VMware vSphere 6.7 Update 1. Теперь эта поддержка была расширена, в том числе для DRS, который теперь учитывает профили vGPU.

Ну и в видео ниже вы можете увидеть обзор технологии Assignable Hardware:

Недавно мы рассказывали о новых возможностях платформы VMware vSphere 7 и прочих обновлениях продуктовой линейки VMware, анонсированных одновременно с флагманским продуктом. Напомним эти статьи:

• Анонсирована новая версия VMware vSphere 7 - что нового?
• Новые возможности VMware Site Recovery Manager 8.3 и vSphere Replication
• Анонсирована новая версия VMware vSAN 7.0 - что там будет интересного?
• Что нового в VMware vRealize Operations 8.1 - самое главное
• Новые возможности решения для виртуализации и доставки настольных ПК предприятия VMware Horizon 7.12
• Новые возможности Dynamic Environment Manager 9.11

Сегодня мы расскажем еще об одном важном апдейте - новой версии набора решений для гибридной инфраструктуры VMware Cloud Foundation 4. О прошлой версии этого пакета VCF 3.9.1 мы писали вот тут. Как вы помните, он представляет собой комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

Четвертая версия VCF включает в себя все самые последние компоненты, статьи с описанием которых мы привели выше:

• vSphere 7
• VMware vSAN 7
• VMware NSX-T
• VMware vRealize Suite 2019
• VMware Tanzu с поддержкой Kubernetes

Как мы видим, в стеке VCF появился принципиально новый компонент - VMware Tanzu Kubernetes Grid. Об инфраструктуре поддержки контейнеров в новой версии платформы vSphere мы уже писали тут и тут. В новой архитектуре VCF администраторы могут развертывать и обслуживать приложения в кластерах Kubernetes с помощью Kubernetes tools и restful API.

В то же время, технология vSphere with Kubernetes (она же Project Pacific) будет обеспечивать следующую функциональность:

• Службы vSphere Pod Service на базе Kubernetes позволят исполнять узлы напрямую в гипервизоре ESXi. Когда администратор развертывает контейнеры через службы vSphere Pod Service, они получают тот же уровень безопасности, изоляции и гарантии производительности, что и виртуальные машины.
• Службы Registry Service позволяют разработчикам хранить и обслуживать образы Docker и OCI на платформе Harbor.
• Службы Network Service позволяют разработчикам управлять компонентами Virtual Routers, Load Balancers и Firewall Rules.
• Службы Storage Service позволяют разработчикам управлять постоянными (persistent) дисками для использования с контейнерами, кластерами Kubernetes и виртуальными машинами.

Все это позволяет получить все преимущества гибридной инфраструктуры (ВМ+контейнеры), о которых интересно рассказано здесь.

В остальном, VCF 4 приобретает все самые новые возможности, которые дают уже перечисленные новые релизы продуктов vSphere, vSAN, NSX-T и прочие.

Отдельно надо отметить очень плотную интеграцию vSphere Lifecycle Manager (vLCM) с платформой vSphere 7. vLCM дополняет возможности по управлению жизненным циклом компонентов инфраструктуры виртуализации, которые уже есть в SDDC Manager, но на более глубоком уровне - а именно на уровне управления firmware для узлов vSAN ReadyNodes (например, обновления микрокода адаптеров HBA).

Как и все прочие обновления линейки vSphere, апдейт VCF 4.0 ожидается уже в апреле. За обновлениями можно следить на этой странице.

Как все уже знают, в скором времени компания VMware сделает доступной для загрузки обновленную платформу виртуализации VMware vSphere 7. О новых возможностях этого решения мы уже писали, а также рассказывали об отдельных улучшениях подробнее (например, о новом DRS).

Сегодня мы поговорим о службах Identity Federation, появившихся в VMware vSphere 7.

В современном мире в корпоративной инфраструктуре все чаще отходят от устаревшей аутентификации по паролям и переходят к практикам двухфакторной (2FA) или многофакторной (MFA) аутентификации. Процесс идентификации пользователей всегда основан на 3 ключевых вещах: что-то вы знаете (пароль), что-то у вас есть (телефон) или кем-то вы являетесь (отпечаток пальца).

Службы Identity Federation позволяют объединить инфраструктуру vCenter Server с другими Identity Providers, такими как Active Directory Federation Services (ADFS), в целях унификации процесса двух- или многофакторной авторизации. Иными словами, пользователи, логинящиеся через 2FA в свой десктоп или в облачный сервис, будут использовать ту же самую процедуру и для операций с vCenter Server.

Будучи подключенным к одному из провайдеров аутентификации (например, ADFS), клиент vSphere Client при логине будет перенаправлять на форму логина данного провайдера. После авторизации на стороне провайдера будет произведено обратное перенаправление с использованием защищенного токена, через который пользователь уже будет работать со службами vCenter.

С точки зрения пользовательского опыта это напоминает, например, логин на веб-сайт с помощью Google или Facebook. Для обмена информацией используются протоколы OAUTH2 и OIDC.

Если вы включите Identity Federation, вы сможете пользоваться традиционными службами Active Directory, Integrated Windows Authentication и LDAP/LDAPS для аутентификации в vCenter Server. Однако надо понимать, что все эти методы аутентификации не затрагивают vSphere Single Sign-on (SSO), который, по-прежнему, используется для внесения административных настроек в саму платформу vSphere.

Более подробно об этом механизме рассказывает Bob Plankers в видео ниже:

Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 7, среди которых мы вкратце рассказывали о нововведениях механизма динамического распределения нагрузки на хосты VMware DRS. Давайте взглянем сегодня на эти новшества несколько подробнее.

Механизм DRS был полностью переписан, так как его основы закладывались достаточно давно. Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом, то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин:

При этом раньше DRS запускался каждые 5 минут. Теперь же этот механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness). Это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness. Расчеты по памяти теперь основываются на Granted Memory вместо стандартного отклонения по кластеру.

Мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (Memory Overcommit), поэтому вместо "Active Memory" DRS 2.0 использует параметр "Granted Memory".

VM Happiness - это основной KPI, которым руководствуется DRS 2.0 при проведении миграций (то есть главная цель всей цепочки миграций - это улучшить этот показатель). Также эту оценку можно увидеть и в интерфейсе:

Как видно из картинки, DRS Score квантуется на 5 уровней, к каждому из которых относится определенное количество ВМ в кластере. Соответственно, цель механизма балансировки нагрузки - это увеличить Cluster DRS Score как агрегированный показатель на уровне всего кластера VMware HA / DRS.

Кстати, на DRS Score влияют не только метрики, касающиеся производительности. Например, на него могут влиять и метрики по заполненности хранилищ, привязанных к хостам ESXi в кластере.

Надо понимать, что новый DRS позволяет не только выровнять нагрузку, но и защитить отдельные хосты ESXi от внезапных всплесков нагрузки, которые могут привести виртуальные машины к проседанию по производительности. Поэтому главная цель - это держать на высоком уровне Cluster DRS Score и не иметь виртуальных машин с низким VM Hapiness (0-20%):

Таким образом, фокус DRS смещается с уровня хостов ESXi на уровень рабочих нагрузок в виртуальных машинах, что гораздо ближе к требованиям реального мира с точки зрения уровня обслуживания пользователей.

Если вы нажмете на опцию View all VMs в представлении summary DRS view, то сможете получить детальную информацию о DRS Score каждой из виртуальных машин, а также другие важные метрики:

Ну и, конечно же, на улучшение общего DRS Score повлияет увеличения числа хостов ESXi в кластере и разгрузка его ресурсов.

Кстати, ниже приведен небольшой обзор работы в интерфейсе нового DRS:

Еще одной важной возможностью нового DRS является функция Assignable Hardware. Многие виртуальные машины требуют некоторые аппаратные возможности для поддержания определенного уровня производительности, например, устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU. В этом случае теперь DRS позволяет назначить профили с поддержкой данных функций для первоначального размещения виртуальных машин в кластере.

В видео ниже описано более подробно, как это работает:

Ну и надо отметить, что теперь появился механизм Scaleable Shares, который позволяет лучше выделять Shares в пуле ресурсов с точки зрения их балансировки. Если раньше высокий назначенный уровень Shares пула не гарантировал, что виртуальные машины этого пула получат больший объем ресурсов на практике, то теперь это может использоваться именно для честного распределения нагрузки между пулами.

Этот механизм будет очень важным для таких решений, как vSphere with Kubernetes и vSphere Pod Service, чтобы определенный ярус нагрузок мог получать необходимый уровень ресурсов. Более подробно об этом рассказано в видео ниже:

Недавно мы рассказывали о новых возможностях анонсированной платформы виртуализации VMware vSphere 7. В составе этого решения идет новая версия управляющего сервера VMware vCenter 7, особенности апгрейда на который мы сегодня рассмотрим.

Основные нюансы этого процесса суммаризованы в видео ниже:

Давайте посмотрим на это немного подробнее:

1. Особенности развертывания

Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).

Напомним также, что теперь у вас нет установщика vCenter Server for Windows. Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь это только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS.

Ранее мы писали, что с помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:

Также установщик vCenter 7 производит апгрейд vCenter и перенос всех сервисов на Embedded PSC в рамках единой задачи, поэтому результат апгрейда будет сразу законченным. Установщик нового vCenter 7 не имеет опции по развертыванию внешнего PSC:

2. Процесс миграции

Если вы проходите путь миграции с vCenter Server for Windows на vCenter Server Appliance (VCSA), то схема будет точно такой же - в итоге вы получите vCenter 7 на vCSA в встроенным PSC:

После того, как внешний PSC будет сконвертирован, он останется в консоли, и его удаление (decomission) - последующая задача администратора vSphere. Сделать это можно с помощью команды CMSSO-UTIL или из графического интерфейса клиента (в разделе System Configuration):

3. Пути апгрейда

Тут все просто. Апгрейд поддерживается согласно вот этой табличке:

Как видно из таблицы, апгрейд поддерживается, начиная с версии vSphere 6.5, но многие администраторы при обновлении виртуальной инфраструктуры предпочитают развертывать сервисы vCenter заново, чтобы не тащить за собой историю возможных багов, которые могут проявиться при апгрейде.

Перед апгрейдом нужно обязательно посмотреть документы VMware Product Interoperability Matrices и VMware Compatibility Guide. Но помните, что до официального выпуска vSphere 7, эти документы не содержат актуальной информации о седьмой версии.

В декабре прошлого года мы писали о выпуске обновленной версии платформы для виртуализации и доставки настольных ПК предприятия VMware Horizon 7.11. Тогда в продукте появилось весьма много новых возможностей, если учитывать, чего его версия увеличилась всего на 0.01. На днях, после больших релизов VMware vSphere 7, vSAN 7 и vRealize Operations 8.1, компания VMware анонсировала новую версию Horizon 7.12, которая следует традиции прошлого выпуска - небольшое увеличение версии, но довольно много новых возможностей.

Одновременно с апдейтом Horizon 7.12 были обновлены и все клиенты до версий VMware Horizon Clients 5.4.

Давайте посмотрим, что именно интересного появилось в VMware Horizon 7.12:

1. Обновления платформы

В этой категории были сделаны следующие улучшения:

• Возможности назначения нескольких пользователей одному полному клону десктопа (Multi-User Assignment). Это пригодится для сменных рабочих, разработчиков и тестеров, а также персоналу поддержки. Это может применяться к автоматическим пулам, содержащим полные клоны ВМ, ручным пулам, а также пулам мгновенных клонов (instant-clone).
• Отображение имени машины в Horizon Client, когда пользователь логинится на хост, вместо имени пула.
• Новые и обновленные функции REST API предоставляют новые возможности автоматизации, где теперь есть 50 новых endpoints, таких как службы Image Management Service, Universal Broker, Configuration и Inventory.

• Новый временной лимит подогретых сессий позволяет еще больше сократить время логина. Первый логин за день занимает больше всего времени, чем остальные входы в гостевую ОС в течение дня. Теперь и первый логин происходит очень быстро, для этого Prewarm Time Limit составляет 30 минут по умолчанию.
• MAC-адреса теперь сохраняются в случае, если пул мгновенных клонов или ферма RDSH ресинхронизируется или делает операцию Refresh. Также есть поддержка SDDC из одного хоста для VMware Cloud on AWS, поддержка vmCrypt и мгновенных клонов в vSphere 7.0. Это все тоже очень удобно для сменных работников, использующих один десктоп.

2. Публикуемые приложения

В этой категории появилось одно улучшение - VM Hosted Applications. Оно позволяет предзапустить приложение в десктопе или пуле RDSH перед тем, как пользователь открывает приложение в Horizon Client. Это позволяет ускорить запуск приложений. Временной лимит настраивается через групповую политику.

3. Улучшения Horizon Console

• Для опубликованных приложений (RDSH и VM hosted applications) видно число пользователей их использующих и общее число возможных пользователей.
• Для каждого Connection Server можно посмотреть число сессий gateway и non-gateway.
• Дэшборд Summary Detail отображает детальные статистики так же, как и старая FLEX-консоль.
• Возможность использования принудительной Force 2-Factor реаутентификации (после истечения срока действия пользовательской сессии).
• Агрегированная статистика узлов Cloud Pod теперь представлена в отдельном разделе, где видно число используемые и брокерируемых сессий для всех узлов.
• Поддержка нескольких вкладок для Horizon Console, что очень удобно для администратора.
• В утилите Horizon Help Desk Tool можно искать процессы или приложения в сессии по имени (в поле filter).

4. Пакет Horizon GPO Bundle

• Возможность/невозможность использования существующего экземпляра клиента при соединении с тем же сервером.
• Настройка параметра HEVC High Color Accuracy.
• Настройки UDP применяются теперь при завершении сессии, а не при перезагрузке.
• Возможность отключить перенаправление принтера для недесктопного клиента.
• Настройка имени принтера для агентов RDSH.
• Возможность настройки списка URL Redirection whitelist.

5. Новые возможности клиентов

• Windows Client
  • Возможность использовать вложенные виртуальные машины Windows 10 1909 и server 2019
  • Улучшения пользовательского интерфейса
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure

• iOS Client
  • Поддержка Derived Credentials ActivClient
  • Поддержка Horizon Universal Broker
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure

• Mac Client
  • Поддержка Horizon Universal Broker
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure

• Linux Client
  • Поддержка Red Hat 8.1
  • Поддержка Horizon Universal Broker
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Настройка клиента для передачи клавиши ESX в рабочий стол Windows гостевой ОС
  • Возможность перезапуска VDI сервисов из клиента
  • Поддержка перенаправления URL
  • Синхронизация клавиши
  • Поддержка WVD для Horizon Cloud on Azure

• Chrome Native
  • Поддержка Derived Credentials ActivClient
  • Поддержка Horizon Universal Broker
  • Поддержка VMware Integrated Printing
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure

• Arc++ Chrome Client
  • Поддержка Derived Credentials ActivClient

• Windows 10 UWP Client
  • Поддержка Horizon Universal Broker

• Android Client
  • Поддержка Horizon Universal Broker
  • Больше настроек для консоли Google Admin
  • Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
  • Поддержка WVD для Horizon Cloud on Azure
  • Поддержка перенаправления USB

• HTML5 Client
• Поддержка Horizon Universal Broker
• Возможность принудительной двухфакторной аутентификации после периода неактивности десктопа
• Поддержка WVD для Horizon Cloud on Azure
• Нативный запуска клиента HTML Access
• UAG 3.8+

Скачать VMware Horizon 7.12 можно по этой ссылке. Release Notes доступны тут.

Одновременно с анонсом новой версии платформы виртуализации VMware vSphere 7 компания VMware объявила и о скором выпуске решения vRealize Operations 8.1, предназначенного для управления и мониторинга виртуальной инфраструктуры. Напомним, что о прошлой версии vROPs 8.0 в рамках анонсов VMworld 2019 мы писали вот тут.

Давайте посмотрим, что нового появилось в vRealize Operations 8.1:

1. Операции с интегрированной инфраструктурой vSphere и Kubernetes.

vRealize Operations 8.1 позволяет обнаруживать и мониторить кластеры Kubernetes в рамках интегрированной с vSphere инфраструктуры с возможностью автодобавления объектов Supervisor Cluster, пространств имен (Namespaces), узлов (PODs) и кластеров Tanzu Kubernetes, как только вы добавите их в vCenter, используя функции Workload Management.

После этого вам станут доступны страницы Summary для мониторинга производительности, емкости, использования ресурсов и конфигурации Kubernetes на платформе vSphere 7.0. Например, функции Capacity forecasting покажут узкие места инфраструктуры на уровне узлов, а для ежедневных операций будут полезны дашборды, отчеты, представления и алерты.

2. Операции в инфраструктуре VMware Cloud on AWS.

Теперь в облаке VMware Cloud on AWS можно использовать токен VMware Cloud Service Portal для автообнаружения датацентров SDDC и настройки средств мониторинга в несколько простых шагов. Также можно будет использовать один аккаунт для управления несколькими объектами SDDC на платформе VMware Cloud on AWS, включая сервисы vCenter, vSAN и NSX, а также будет полная интеграция с биллингом VMConAWS.

В облаке можно использовать следующие дашборды:

• Отслеживание использования ресурсов и производительность виртуальных машин, включая сервисы NSX Edge, Controller и vCenter Server.
• Мониторинг ключевых ресурсов, включая CPU, память, диск и сеть для всей инфраструктуры и виртуальных машин.
• Отслеживание трендов потребления ресурсов и прогнозирование таких метрик, как Time Remaining, Capacity Remaining и Virtual Machines Remaining.
• Нахождение виртуальных машин, которые потребляют неоправданно много ресурсов и требуют реконфигурации на базе исторических данных.

Кроме этого, для сервисов VMware NSX-T будет осуществляться полная поддержка средств визуализации и мониторинга:

Ну и в релизе vROPs 8.1 есть полная интеграция функционала отслеживания затрат VMware Cloud on AWS с решением vRealize Operations в интерфейсе портала. Это позволит контролировать уже сделанные и отложенные затраты, а также детализировать их по подпискам, потреблению и датам оплат.

Также обновился механизм обследования AWS migration assessment, который теперь позволяет сохранять несколько результатов разных сценариев для дальнейшего анализа. Эти сценарии включают в себя различные варианты параметров Reserved CPU, Reserved Memory, Fault Tolerance, Raid Level и Discounts.

3. Функции мониторинга нескольких облаков (Unified Multicloud monitoring).

Теперь средства мониторинга предоставляют еще более расширенные функции, такие как поддержка Google Cloud Platform, улучшенная поддержка AWS и новый пакет Cloud Health Management pack.

Теперь в vROPS 8.1 есть следующие сервисы GCP:

• Compute Engine Instance
• Storage Bucket
• Cloud VPN
• Big Query
• Kubernetes Engine

Пакет AWS Management Pack теперь поддерживает следующие объекты AWS Objects:

• EFS
• Elastic Beanstalk
• Direct Connect Gateway
• Target Group
• Transit Gateway
• Internet Gateway
• Elastic Network Interface (ENI)
• EKS Cluster

Пакет CloudHealth Management Pack был также улучшен, он включает в себя возможность передать данные о перспективах и ценообразовании GCP в vRealize Operations 8.1. Также вы сможете создавать любое число кастомных дэшбордов, комбинируя цены на различное соотношение ресурсов публичного, гибридного или частного облаков.

Как ожидается, vRealize Operations 8.1 выйдет в апреле этого года одновременно с релизом VMware vSphere 7. Мы обязательно напишем об этом.

На днях компания VMware сделала много важных анонсов, о двух из них мы уже рассказали:

• Анонсирована новая версия VMware vSphere 7 - что нового?
• Анонсирована новая версия VMware vSAN 7.0 - что там будет интересного?

Одновременно с этим было объявлено и о скором выпуске обновленной версии решения VMware Site Recovery Manager 8.3, предназначенного для обеспечения катастрофоустойчивости виртуальных датацентров. Напомним, что о прошлой версии SRM 8.2 мы писали в мае прошлого года. Главной новой возможностью тогда стала реализация функций продукта в виртуальном модуле (Virtual Appliance) на базе Photon OS.

Давайте посмотрим, что нового появилось в SRM 8.3:

1. Интеграция с Virtual Volumes (vVols).

Это было одной из самых ожидаемых возможностей SRM. Теперь тома vVols полностью поддерживаются для защиты с помощью SRM на базе технологий репликации на уровне дискового массива. Репликация для томов vVols работает на уровне отдельных виртуальных машин, а также в составе групп (replication groups).

Как некоторые знают, компонент VASA provider заменил модуль SRA (Storage Replication Adaptor), поэтому ежедневные операции теперь выполняются проще и быстрее. Сначала поддержка будет реализована для хранилищ Pure, HPE 3par и Nimble, но вскоре появится и для других вендоров. Список совместимости доступен здесь и будет постоянно обновляться.

2. Автоматическая защита виртуальных машин.

Раньше если вам было необходимо добавить ВМ в защищаемые на protected datastore, нужно было открыть консоль SRM и добавить ее в protection group. Теперь же, если машина перемещается на такой датастор с помощью vMotion или создается там администратором, то она автоматически попадает в состав защищенной группы.

Точно такая же автоматическая защита теперь распространяется и на тома vVols, которые поддерживаются, начиная с этой версии SRM.

Надо отметить, что если машина перемещается между датасторами через Storage vMotion, то она не попадает в protection group. Это сделано для того, чтобы предотвратить изменение protection group для машины во время этой операции.

3. Бесшовное изменение размера диска.

Раньше для изменения размера диска реплицируемой машины средствами vSphere Replication требовалось сделать несколько ручных операций на стороне таргета репликации. Теперь же эта операция делается автоматически, когда вы меняете размер диска исходной ВМ.

4. Утилита vSphere Replication Configuration Export/Import Tool.

В SRM 8.1 появилась возможность сохранять и восстанавливать конфигурацию защищаемой среды, а в SRM 8.3 с помощью утилиты vSphere Replication Configuration Export/Import Tool можно делать то же самое для конфигураций репликации. Теперь администраторы могут сделать резервную копию конфигураций реплицируемых ВМ, включая RPO, MPIT, компрессии, подморозки (quiescing), шифрования, настройки датасторов и все прочее. Пока эта возможность доступна только через CLI.

5. Улучшения интерфейса.

В плане UI в SRM 8.3 было сделано очень много изменений, вот лишь некоторые из них:

• Улучшения репортинга, включая возможность экспорта всех представлений в формат CSV.
• Пользователь теперь может экспортировать детали репликации отдельных ВМ.
• Интерфейс репликации теперь включает статистику lag time, которая показывает прошедшее с момента последней репликации время.
• Возможность спрятать/показать колонки во всех табличных представлениях.
• Список replications list теперь показывает ассоциированные protection groups.

6. Улучшения производительности vSphere Replication.

Инженеры VMware приложили много усилий для внесения оптимизаций в эту версию vSphere Replication. Улучшения касаются как механизма первоначальной синхронизации, так и постоянной репликации машины под нагрузкой.

7. Прочие улучшения.

• Улучшения утилиты SRM Configuration Import/Export Tool.
• Расширенные возможности плагинов vRO для SRM и vSphere Replication, включая рабочие процессы для томов vVols.
• Новые возможности для vROps Management packs, как для SRM, так и для vSphere Replication.
• Улучшенная интеграция с хранилищами vSAN, которые теперь больше понимают о наличии данных реплик vSphere Replication.
• Улучшения безопасности, включая поддержку FIPS в интерфейсе, и интеграция с шифрованием vSphere Trust Authority.

Доступность для загрузки VMware Site Recovery Manager 8.3 ожидается в апреле, одновременно с релизами vSphere 7 и vSAN 7. Пока за обновлениями можно следить на этой странице.

На днях компания VMware объявила о скором выпуске платформы виртуализации VMware vSphere 7.0, где будет много интересных новых возможностей. Одновременно с этим было объявлено и о будущем релизе новой версии VMware vSAN 7.0 - решения для организации отказоустойчивых хранилищ для виртуальных машин на базе локальных хранилищ хост-серверов VMware ESXi.

Давайте посмотрим, что интересного было анонсировано в новой версии решения VMware vSAN 7:

1. Интеграция с vSphere Lifecycle Manager (vLCM) для обновления кластеров

Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager:

vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Это упрощает мониторинг инфраструктуры на предмет своевременных обновлений и соответствия компонентов руководству VMware Compatibility Guide (VCG) за счет централизованного подхода на уровне всего кластера.

2. Службы Native File Services for vSAN

С помощью служб Native File Services кластер vSAN теперь поддерживает управление внешними хранилищами NFS v3 и v4.1. Это позволяет использовать их совместно с другими возможностями, такими как службы iSCSI, шифрование, дедупликация и компрессия. Теперь через интерфейс vCenter можно управлять всем жизненным циклом хранилищ на базе разных технологий и превратить его в средство контроля над всей инфраструктурой хранения.

3. Развертывание приложений с использованием Enhanced Cloud Native Storage

Напомним, что функции Cloud Native Storage появились еще VMware vSAN 6.7 Update 3. Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Теперь эти функции получили еще большее развитие. Тома persistent volumes могут поддерживать шифрование и снапшоты. Также полностью поддерживается vSphere Add-on for Kubernetes (он же Project Pacific), который позволяет контейнеризованным приложениям быть развернутыми в кластерах хранилищ vSAN.

4. Прочие улучшения

Тут появилось довольно много нового:

• Integrated DRS awareness of Stretched Cluster configurations. Теперь DRS отслеживает, что виртуальная машина находится на одном сайте во время процесса полной синхронизации между площадками. По окончании процесса DRS перемещает машину на нужный сайт в соответствии с правилами.
• Immediate repair operation after a vSAN Witness Host is replaced. Теперь процедура замены компонента Witness, обеспечивающего защиту от разделения распределенного кластера на уровне площадок, значительно упростилась. В интерфейсе vCenter есть кнопка "Replace Witness", с помощью которой можно запустить процедуру восстановления конфигурации и замены данного компонента.
• Stretched Cluster I/O redirect based on an imbalance of capacity across sites. В растянутых кластерах vSAN можно настраивать защиту от сбоев на уровне отдельных ВМ за счет выделения избыточной емкости в кластере. В результате на разных площадках могут оказаться разные настройки, и появится дисбаланс по доступной емкости и нагрузке по вводу-выводу. vSAN 7 позволяет перенаправить поток ввода-вывода на менее загруженную площадку прозрачно для виртуальных машин.
• Accurate VM level space reporting across vCenter UI for vSAN powered VMs. Теперь в vSAN 7 есть возможности точной отчетности о состоянии хранилищ для виртуальных машин, точно так же, как и для остальных хранилищ в представлениях Cluster View и Host View.
• Improved Memory reporting for ongoing optimization. Теперь в интерфейсе и через API доступна новая метрика потребления памяти во времени. Она позволяет понять, как меняется потребление памяти при изменениях в кластере (добавление и удаление хостов, изменение конфигурации).
• Visibility of vSphere Replication objects in vSAN capacity views. vSAN 7 позволяет администраторам идентифицировать объекты vSphere Replication на уровне виртуальных машин и кластеров, что упрощает управление ресурсами для нужд репликации.
• Support for larger capacity devices. Теперь vSAN 7 поддерживает новые устройства хранения большой емкости и плотности носителей.
• Native support for planned and unplanned maintenance with NVMe hotplug. Для устройств NVMe теперь доступна функция горячего добавления и удаления, что позволяет сократить время и упростить процедуру обслуживания.
• Removal of Eager Zero Thick (EZT) requirement for shared disk in vSAN. Теперь общие диски в vSAN не требуется создавать в формате EZT, что ускоряет развертывание в кластере vSAN нагрузок, таких как, например, Oracle RAC.

Больше информации о новых возможностях можно почитать в даташите о vSAN 7. Ну а технические документы будут постепенно появляться на StorageHub. Как и VMware vSphere 7, планируется, что решение vSAN 7 выйдет в апреле этого года.

На днях, как вы знаете, было много интересных новостей. И вот еще одна - компания VMware анонсировала большое обновление своей флагманской платформы виртуализации VMware vSphere 7. Напомним, что прошлая мажорная версия этого решения VMware vSphere 6.7 вышла весной 2018 года.

Сразу скажем, что это лишь анонс, а не объявление о доступности новой версии продукта для скачивания - как правило, GA версия vSphere появляется в течение месяца после анонса. Поэтому будем пока ожидать VMware vSphere 7 в апреле, а сегодня расскажем о новых возможностях этой платформы.

1. Улучшения сервисов VMware vCenter

Здесь можно отметить упрощение топологии vCenter Server SSO:

• Возможность апгрейда vCenter Server для пользователей с внешним PSC на консолидированную топологию на базе одного сервера vCSA.
• Embedded PSC теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается.

Профили vCenter Server Profiles:

• Эта новая возможность для серверов vCenter работает точно так же, как Host Profiles работает для хостов. Теперь вы можете сравнивать и экспортировать настройки серверов vCenter в формате JSON для целей резервного копирования или применения этих настроек к другому серверу vCenter через REST API.

Функции vCenter Multi-Homing:

• Теперь для управляющего трафика vCSA можно использовать до 4 адаптеров vNIC, среди которых один vNIC зарезервирован для механизма vCHA.

Улучшения Content Library

• Теперь появилось новое представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для управления версиями шаблонов и возможностью откатиться к предыдущей версии.
• Сначала делается Check-Out для открытия возможности внесения изменений, потом можно сделать Check-In для сохранения изменений в библиотеке.

Новая функция vCenter Server Update Planner:

• Новая возможность доступна как часть vSphere Lifecycle Manager (vLCM) для серверов vCenter.
• С помощью планировщика обновлений можно получать оповещения об обновлениях vCenter, планировать апгрейды, накатывать их, а также проводить анализ "что если" перед проведением обновления.
• Возможность выполнения pre-upgrade проверок для выбранного сервера vCenter.

2 Улучшения механизма VMware DRS

• Теперь DRS запускается каждую минуту, а не каждые 5 минут, как раньше.
• Для генерации рекомендаций используется механизм VM DRS score (он же VM Hapiness).
• Теперь это Workload centric механизм - это означает, что теперь в первую очередь учитываются потребности самой виртуальной машины и приложения в ней, а только потом использование ресурсов хоста.
• Расчеты по памяти основываются на granted memory вместо стандартного отклонения по кластеру.
• Появился механизм Scaleable Shares, который позволяет лучше выделать Shares в пуле ресурсов с точки зрения их балансировки.

3. Улучшения vMotion

Тут появились такие улучшения:

• Улучшения миграций для Monster VM (с большими ресурсами и очень высокой нагрузкой), что позволяет увеличить шанс успешной миграции.
• Использование только одного vCPU при отслеживании изменившихся страниц (page tracer) вместо всех vCPU, что меньше влияет на производительность во время миграции.
• Уменьшение времени переключения контекста на другой сервер (теперь меньше одной секунды). Достигается за счет переключения в тот момент, когда compacted memory bitmap уже передана на целевой сервер, вместо ожидания передачи full bitmap.

4. Новые функции vSphere Lifecycle Manager (vLCM)

Здесь можно отметить 2 улучшения:

• Функция Cluster Image Management, которая включает обновления firmware, драйверов и образов ESXi разных версий.
• Первоначальная поддержка решений Dell OpenManage и HP OneView.

5. Возможности Application Acceleration (Tech Preview)

Эти функции пришли от приобретенной компании Bitfusion. Они позволяют оптимизировать использование GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может использоваться для рабочих нагрузок задач приложений AI/ML.

Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети. Подробнее можно почитать у нас тут.

6. Функции Assignable Hardware

Эта возможность позволяет использовать так называемый Dynamic DirectPath I/O для машин, которым требуется работа с устройствами PCIe passthrough и Nvidia GRID. Теперь с его помощью можно подобрать хосты с определенными требованиями к аппаратным компонентам, такими как vGPU и PCIe. Это позволяет, в свою очередь, использовать для таких ВМ технологии HA и DRS Initial Placement в кластере, где есть совместимые по оборудованию хосты ESXi.

7. Управление сертификатами

Здесь 2 основных новых возможности:

• Новый мастер импорта сертификатов.
• Certificate API для управления сертификатами с помощью сценариев.

8. Возможности Identity Federation

Функции ADFS теперь поддерживаются из коробки, также будет поддерживаться больше IDP, использующих механизмы OAUTH2 и OIDC.

9. Функции vSphere Trust Authority (vTA)

• vTA использует отдельный кластер хостов ESXi, чтобы создать отдельный аппаратный узел доверия.
• Этот кластер сможет зашифровывать вычислительный кластер и его ВМ вместе с vCenter и другими управляющими компонентами.
• Можно использовать механизм аттестации, когда требуются ключи шифрования.
• Теперь проще добиться соблюдения принципа наименьших привилегий, а также расширить пространство аудита.

10. Возможность vSGX / Secures Enclaves (Intel)

• Расширения Intel Software Guard Extensions (SGX) позволяют переместить чувствительную логику и хранилище приложения в защищенную область, к которой не имеют доступа гостевые ОС и гипервизор ESXi.
• Возможности SGX исключают использование vMotion, снапшотов, Fault Tolerance и других технологий. Поэтому SGX лучше использовать только тогда, когда по-другому нельзя.

11. Новое издание vSphere with Kubernetes (Project Pacific)

О Project Pacific мы подробно рассказывали вот тут. Он представляет собой набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes. vCenter Server предоставляет возможности по управлению кластерами k8s (любые кластеры старше n-2 будут обновлены). Также в решение интегрирован Harbor, который может быть включен для каждого пространства имен.

Доступно это пока только для пользователей VMware Cloud Foundation (4.0), так как решение завязано на компонент VMware NSX-T.

12. Улучшения VMware Tools

Функции Guest Store теперь доступны в гостевой ОС (такие как обновление VMware Tools из гостевой ОС).

13. Обновленное железо (VM Hardware v17)

Тут основные улучшения таковы:

• Virtual Watchdog Timer - теперь нет зависимости от физического железа для рестарта ВМ в случае, если гостевая ОС не отвечает.
• Precision Time Protocol (PTP) - для приложений очень чувствительных ко времени (например, торговые платформы для трейдеров) можно использовать PTP вместо NTP и назначать его использование для виртуальных машин.

14. Улучшения vSphere Client

Здесь появились следующие улучшения:

• Начала сохраняться история поиска.
• В API Explorer теперь лучше видны все доступные API.
• Для Code Capture появилась возможность выбора языка сценариев - PowerCLI, Javascript, Python или Go.

Конечно же, это далеко не все новые возможности VMware vSphere 7, представленные на днях. В ближайшее время мы расскажем еще много нового о них, а кроме того, посмотрим также и на анонсированные решения семейства VMware Tanzu, VMware Cloud Foundation 4 и vRealize 8.1.

В блоге VMware vSphere появилась интересная запись о том, как происходит работа с памятью в гипервизоре VMware ESXi. Приведем ее основные моменты ниже.

Работа виртуальной машины и ее приложений с памятью (RAM) идет через виртуальную память (Virtual Memory), которая транслируется в физическую память сервера (Physical Memory). Память разбита на страницы - это такие блоки, которыми виртуальная память отображается на физическую. Размер этого блока у разных систем бывает разный, но для ESXi стандартный размер страниц равен 4 КБ, а больших страниц - 2 МБ.

Для трансляции виртуальных адресов в физические используется таблица страниц (Page Table), содержащая записи PTE (Page Table Entries):

Записи PTE хранят в себе ссылки на реальные физические адреса и некоторые параметры страницы памяти (подробнее можно почитать здесь). Структуры записей PTE могут быть разного размера - это WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) и QWORD (64 bits/8 bytes). Они адресуют большие блоки адресов в физической памяти, к примеру, DWORD адресует блок адресов 4 килобайта (например, адреса от 4096 до 8191).

Память читается и передается гостевой системе и приложениям страницами по 4 КБ или 2 МБ - это позволяет читать содержимое ячеек памяти блоками, что существенно ускоряет быстродействие. Естественно, что при таком подходе есть фрагментация памяти - редко когда требуется записать целое число страниц, и часть памяти остается неиспользуемой. При увеличении размера страницы растет и их фрагментация, но увеличивается быстродействие.

Таблицы страниц (а их может быть несколько) управляются программным или аппаратным компонентом Memory Management Unit (MMU). В случае аппаратного MMU гипервизор передает функции по управлению трансляцией ему, а программный MMU реализован на уровне VMM (Virtual Machine Monitor, часть гипервизора ESXi):

Важный компонент MMU - это буфер ассоциативной трансляции (Translation Lookaside Buffer, TLB), который представляет собой кэш для MMU. TLB всегда находится как минимум в физической памяти, а для процессоров он часто реализован на уровне самого CPU, чтобы обращение к нему было максимально быстрым. Поэтому обычно время доступа к TLB на процессоре составляет около 10 наносекунд, в то время, как доступ к физической памяти составляет примерно 100 наносекунд. VMware vSphere поддерживает Hardware MMU Offload, то есть передачу функций управления памятью на сторону MMU физического процессора.

Итак, если от виртуальной машины появился запрос на доступ к виртуальному адресу 0x00004105, то этот адрес разбивается на адрес виртуальной страницы (Virtual page number - 0x0004) и смещение (Offset - 0x105 - область внутри страницы, к которой идет обращение):

Смещение напрямую передается при доступе к физической странице памяти, а вот тэг виртуальной страницы ищется в TLB. В данном случае в TLB есть запись, что соответствующий этому тэгу адрес физической страницы это 0x0007, соответственно трансляция виртуальной страницы в физическую прошла успешно. Это называется TLB Hit, то есть попадание в кэш.

Возможна и другая ситуация - при декомпозиции виртуального адреса получаемый тэг 0x0003 отсутствует в TLB. В этом случае происходит поиск страницы в физической памяти по тэгу (страницу номер 3) и уже ее адрес транслируется (0x006). Далее запись с этим тэгом добавляется в TLB (при этом старые записи из кэша вытесняются, если он заполнен):

Надо отметить, что такая операция вызывает несколько большую задержку (так как приходится искать в глобальной памяти), и такая ситуация называется TLB Miss, то есть промах TLB.

Но это не самая плохая ситуация, так как счет latency все равно идет на наносекунды. Но доступ может быть и гораздо более долгий (миллисекунды и даже секунды) в том случае, если нужная гостевой ОС страница засвопировалась на диск.

Посмотрим на пример:

Виртуальная машина обратилась к виртуальному адресу 0x00000460, для которого есть тэг 0x0000. В физической памяти для этого тэга выделена страница 0, которая означает, что искать эту страницу нужно на диске, куда страница была сброшена ввиду недостатка физической оперативной памяти.

В этом случае страница восстанавливается с диска в оперативную память (вытесняя самую старую по времени обращения страницу), ну и далее происходит трансляция адреса к этой странице. Эта ситуация называется отказ страницы (Page Fault), что приводит к задержкам в операциях приложения, поэтому иногда полезно отслеживать Page Faults отдельных процессов, чтобы понимать причину падения быстродействия при работе с памятью.

На днях пришла пара важных новостей о продуктах компании StarWind Software, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ для виртуальной инфраструктуры.

StarWind HCA All-Flash

Первая важная новость - это выпуск программно-аппаратного комплекса StarWind HyperConverged Appliance (HCA) All-Flash, полностью построенного на SSD-накопителях. Обновленные аппаратные конфигурации StarWind HCA, выполненные в форм-факторе 1 или 2 юнита, позволяют добиться максимальной производительности хранилищ в рамках разумной ценовой политики. Да, All-Flash постепенно становится доступен, скоро это смогут себе позволить не только большие и богатые компании.

Решение StarWind HCA - это множество возможностей по созданию высокопроизводительной и отказоустойчивой инфраструктуры хранилищ "все-в-одном" под системы виртуализации VMware vSphere и Microsoft Hyper-V. Вот основные высокоуровневые возможности платформы:

• Поддержка гибридного облака: кластеризация хранилищ и active-active репликация между вашим датацентром и любым публичным облаком, таким как AWS или Azure
• Функции непрерывной (Fault Tolerance) и высокой доступности (High Availability)
• Безопасное резервное копирование виртуальных машин
• Катастрофоустойчивость на уровне площадок
• Максимизация производительности за счет RDMA
• Распределенное кэширование
• Проактивная поддержка вашей инфраструктуры специалистами StarWind
• И многое, многое другое

Сейчас спецификация на программно-аппаратные модули StarWind HCA All-Flash выглядит так:

После развертывания гиперконвергентной платформы StarWind HCA она управляется с помощью единой консоли StarWind Command Center.

Ну и самое главное - программно-аппаратные комплексы StarWind HCA All-Flash полностью на SSD-дисках продаются сегодня, по-сути, по цене гибридных хранилищ (HDD+SSD). Если хотите узнать больше - обращайтесь в StarWind за деталями на специальной странице. Посмотрите также и даташит HCA.

Новый StarWind Virtual SAN V8 для Hyper-V

Второй важный релиз - это обновленная версия продукта StarWind Virtual SAN V8 for Hyper-V (билд 13481 от 25 февраля 2020 года).

Давайте посмотрим, что нового появилось в StarWind Virtual SAN V8 for Hyper-V:

Ядро продукта

• Добавлен мастер для настройки StarWind Log Collector. Теперь можно использовать для этого соответствующее контекстное меню сервера в Management Console. Там можно подготовить архив с логами и скачать их на машину, где запущена Management Console.
• Исправлена ошибка с заголовочным файлом, который брал настройки из конфига, но не существовал на диске, что приводило с падению сервиса.
• Улучшен вывод событий в файлы журнала, когда в системе происходят изменения.
• Улучшена обработка ответов на команды UNMAP/TRIM от аппаратного хранилища.
• Добавлена реализация процессинга заголовка и блога данных дайждестов iSCSI на процессорах с набором команд SSE4.2.
• Максимальное число лог-файлов в ротации увеличено с 5 до 20.

• Процедура полной синхронизации была переработана, чтобы избежать перемещения данных, которые уже есть на хранилище назначения. Делается это путем поблочного сравнения CRC и копирования только отличающихся блоков.
• Исправлена ошибка падения сервиса в случае выхода в офлайн партнерского узла при большой нагрузке на HA-устройство.
• Значение по умолчанию пинга партнерского узла (iScsiPingCmdSendCmdTimeoutInSec) увеличено с 1 до 3 секунд.
• Исправлена ошибка с утечкой памяти для состояния, когда один из узлов был настроен с RDMA и пытался использовать iSER для соединения с партнером, который не принимал соединений iSER.

• Реализована поддержка SMTP-соединений через SSL/STARTTLS.
• Добавлена возможность аутентификации на SMTP.
• Добавлена возможность проверки настроек SMTP путем отправки тестового сообщения.

• Список регионов для всех репликаций помещен во внешний файл JSON, который можно просто обновлять в случае изменений на стороне провайдера.
• Исправлена обработка баркодов с длиной, отличающейся от дефолтной (8 символов).
• Исправлена ошибка падения сервиса при загрузке tape split из большого числа частей (тысячи).
• Исправлены ошибки в настройках CloudReplicator Settings.

• Обновился скрипт AddVirtualTape.ps1, был добавлен учет параметров, чувствительных к регистру.
• Для команды Remove-Device были добавлены опциональные параметры принудительного отсоединения, сохранения сервисных данных и удаления хранимых данных на устройстве.
• Добавлен метод IDevice::EnableCache для включения и отключения кэша (смотрите примеры FlashCache.ps1 и FlushCacheAll.ps1).
• VTLReplicationSettings.ps1 — для назначения репликации используется число, кодирующее его тип.
• Свойство "Valid" добавлено к HA channel.
• Сценарий MaintenanceMode.ps1 — улучшенная обработка булевых параметров при исполнении сценария из командной строки.
• Тип устройства LSFS — удален параметр AutoDefrag (он теперь всегда true).

• Небольшие улучшения и исправления ошибок.

Скачать полнофункциональную пробную версию StarWind Virtual SAN for Hyper-V можно по этой прямой ссылке. Release Notes доступны тут.

Как некоторые из вас помнят, компания VMware в 2018 году анонсировала специальное издание vSphere Platinum, которое вышло одновременно с обновлением vSphere 6.7 Update 1. Решение vSphere Platinum стало комбинацией из двух продуктов: платформы VMware vSphere Enterprise Plus и решения VMware AppDefense. Помимо этого, в рамках издания Platinum был достпен специальный плагин для vSphere Client, который реализовывал интеграцию vSphere и AppDefense (называется он vCenter Server plugin for vSphere Platinum).

В целом, решение vSphere Platinum особо нигде не обсуждалось, и, как стало теперь понятно, никем особенно не покупалось. Поэтому VMware решила снять его с производства (End of Availability), начиная со 2 апреля 2020 года. Одновременно с vSphere Platinum в прошлое с этой даты уходят и решения VMware Cloud Foundation Platinum и VMware vCloud Suite Platinum. Компоненты решений продолжат поддерживаться в соответствии с VMware Lifecycle Product Matrix.

Существующие пользователи vSphere Platinum после объявленной даты получат лицензии vSphere Enterprise Plus, SaaS-продукт VMware AppDefense и плагин VMware AppDefense Plugin for vSphere (о том, где скачать этот плагин написано вот тут). Для пользователей vCloud Suite Platinum и Cloud Foundation Platinum ничего не меняется, за исключением эволюции самой vSphere, входящей в состав пакетов.

Многие пользователи платформы VMware vSphere знают, что есть такой вариант развертывания и эксплуатации распределенной виртуальной инфраструктуры как ROBO (Remote or Brunch Offices). Она подразумевает наличие одного или нескольких главных датацентров, откуда производится управление небольшими удаленными офисами, где размещено несколько серверов VMware ESXi под управлением собственного vCenter или без него.

В конце прошлого года компания VMware выпустила интересный документ "Performance of VMware vCenter Server 6.7 in Remote Offices and Branch Offices" (мы уже немного рассказывали о нем тут), где рассматривается главный аспект применения такого сценария - производительность. Ведь удаленные офисы могут располагаться в других городах, странах и даже континентах, доступ к которым осуществляется по разным типам соединений (например, 4G или спутник), поэтому очень важно, сколько трафика потребляют различные операции, и как быстро они отрабатывают с точки зрения администратора.

Параметры различных типов сетевых соединений в VMware свели в табличку (в правой колонке, что получалось в результате использования тестовой конфигурации, а в левой - как бывает в сценариях с реальными датацентрами):

Для тестирования использовалась удаленная конфигурация из 128 хостов ESXi, где было зарегистрировано 3840 виртуальных машин (960 ВМ на кластер, 30 на хост), из которых включалось до 3000 машин одновременно.

Сначала посмотрим на фоновый трафик для синхронизации хостов ESXi и vCenter, в зависимости от числа виртуальных машин на хосте (трафик в сторону vCenter):

Теперь посмотрим на трафик в обратную сторону (там просто передаются команды к хостам, ВМ не сильно затрагиваются, поэтому отличия небольшие):

Теперь посмотрим на то, как отличается объем передаваемого трафика от ESXi к vCenrer в зависимости от уровня собираемой статистики на сервере VMware vCenter:

Теперь давайте посмотрим, как отличается трафик к vCenter в зависимости от числа включенных виртуальных машин на хосте:

Посмотрим на трафик в обратную сторону (от vCenter к хостам ESXi) в зависимости от уровня статистики:

Теперь интересно посмотреть, сколько операций в минуту может выполнять vCenter с удаленными серверами ESXi в зависимости от типа соединения, а также задержки в секундах при выполнении операций:

Теперь посмотрим на задержки при выполнении отдельных операций, в зависимости от типа соединения:

Авторы документа отмечают, что больше всего на производительность операций vCenter влияет не полоса пропускания, а latency между сервером vCenter (который может быть в головном офисе) и хостами ESXi (которые могут быть на удаленной площадке).

Теперь посмотрим на сетевой трафик от хоста ESXi к серверу vCenter, который включает в себя фоновый трафик, а также собираемую статистику Level-1:

Посмотрим на такой трафик в обратную сторону - от ESXi к vCenter:

Ну а теперь посмотрим задержки на выполнение операций уже с хостами ESXi, а не с виртуальными машинами:

И в заключение, посмотрим на трафик от хостов ESXi к серверу vCenter при выполнении операций с хостами:

В общем, очень интересный документ - будет не лишним прочитать его полностью.

На сайте проекта VMware Labs появилась обновленная версия веб-клиента для управления платформой VMware vSphere - HTML5 Web Client 5.0 (он же vSphere Client в релизной редакции vSphere). Напомним, что прошлая версия vSphere Client 4.3 вышла еще в сентябре прошлого года.

Давайте посмотрим, что нового появилось в основном клиенте vSphere, функции которого будут включены в очередной крупный апдейт платформы:

• Новый язык для механизма Code Capture - теперь запись происходящего в интерфейсе может быть транслирована в код на языке Go.
• Операционная система виртуального модуля клиента заменена на Photon OS. Соответственно, обновления на версию 5.0 с более ранних версий не поддерживаются.
• Функция PowerActions - теперь PowerCLI и vSphere Client будут плотно интегрированы (см. раздел Developer Center). Это позволяет исполнять сценарии PowerCLI прямо из vSphere Client, а также сохранять их в библиотеке. Кастомные действия, которые записаны как PowerCLI-сценарии, теперь можно выполнять для заданных объектов из инвентори.
• Чтобы PowerActions заработали, нужно их явно включить во время развертывания виртуального модуля vSphere Client. Для того, чтобы узнать больше об этом механизме, прочитайте документ PowerActions_documentation_Fling50.pdf из состава дистрибутива.

Скачать VMware vSphere Client 5.0 можно по этой ссылке. Там же, выбрав из комбо-бокса, можно загрузить и всю необходимую документацию.

Свершилось. Компания Veeam Software, лидер в сфере средств для обеспечения доступности виртуальных датацентров, объявила о выпуске и доступности для загрузки новой версии пакета Veeam Availability Suite v10, в состав которого входит решение для резервного копирования и репликации виртуальных машин Veeam Backup and Replication v10.

Интересная штука появилась на GitHub - проект VMware Community Homelabs от Вильяма Лама, в котором описаны конфигурации и стоимость аппаратных тестовых лабораторий участников комьюнити VMware, которые они строят у себя дома или где-либо еще за свои деньги.

Самая бюджетная (кстати, у Вильяма Лама) лаба стоит 800 долларов, самая дорогая - 150 000 долларов, средняя - 1152 доллара. Вот так выглядит схема домашней лаборатории почти за 10 миллионов рублей:

А вот за 50 тысяч рублей:

Свою домашнюю лабораторию вы можете добавить в список с помощью вот этой странички.

Интересные вещи делает наш коллега Jorge de la Cruz. Он скрупулезно и дотошно делает полезные дэшборды в Grafana для платформы виртуализации VMware vSphere и решения Veeam Availability Suite, которые могут помочь администраторам в решении повседневных задач мониторинга и траблшутинга.

Вот эти дашборды:

• Grafana vSphere Overview Dashboard – 8159
• Grafana vSphere Datastore Dashboard – 8162
• Grafana vSphere Hosts Dashboard – 8165
• Grafana vSphere VMs Dashboard – 8168

Чтобы сделать доступными функции визуализации этих метрик, вам потребуется развернуть следующие компоненты:

• Коллектор и нативный плагин Telegraf к VMware vSphere - агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - фреймворк, который используется для визуализации метрик из базы.

О том, как это все заставить работать, чтобы получать красивые дашборды, подробно написано вот тут и тут. Ниже мы лишь приведем примеры того, как это выглядит:

1. vSphere Overview Dashboard.

Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами.

Лайв-демо такого дэшборда доступно по этой ссылке.

2. vSphere Datastore Dashboard.

Тут можно найти все метрики, касающиеся хранилищ, включая параметры чтения и записи, и многое другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

3. vSphere Hosts Dashboard.

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

Лайв-демо такого дэшборда доступно по этой ссылке.

4. vSphere VMs Dashboard.

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

5. vSphere Hosts IPMI dashboard.

Этот дэшборд отображает информацию IPMI для серверов Supermicro и HPE, доступную через iLO. Пригодится, когда вам нужно взглянуть на статус ваших систем в распределенной инфраструктуре удаленных офисов и филиалов.

Кроме приведенных выше дэшбордов для VMware vSphere, у Jorge de la Cruz также есть несколько дэшбордов для решений Veeam Software:

• Grafana Dashboard for Veeam Availability Console - SP Overview
• Grafana Dashboard for Veeam Availability Console - Tenant Overview
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0 - Security and Performance
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v4

Ну в заключение, стоит отметить еще один дэшборд автора - Microsoft Azure Storage.

Не так давно мы писали о политиках хранилищ SPBM на базе тэгов в кластере VMware vSAN. Это один из механизмов категоризации объектов, который может применяться не только к хранилищам, но и хостам, виртуальным машинам и другим объектам. Появился он еще в версии VMware vSphere 5.1.

На днях компания VMware выпустила интересный документ VMware vSphere 6.7 Tagging Best Practices, в котором описаны лучшие практики по использованию тэгов в виртуальной инфраструктуре.

В документе рассматривается использование API для тэгов, работа с которым происходит через интерфейсы Java или PowerShell.

Например, вот команда по выводу всех виртуальных машин, которым назначен определенный тэг:

// List tags associated with tagId from above
// Assumes tagAssociation object from above
List retDynamicIds = tagAssociation.listAttachedObjects(tagId);

А вот так можно вывести список всех тэгов для конкретной виртуальной машины:

$allCategoryMethodSVC = Get-CisService com.vmware.cis.tagging.category
$alltagMethodSVC = Get-CisService com.vmware.cis.tagging.tag
$allTagAssociationMethodSVC = Get-CisService com.vmware.cis.tagging.tag_association
# Use first VM from above list
$useThisVMID = $useTheseVMIDs[0]
$tagList = $allTagAssociationMethodSVC.list_attached_tags($useThisVMID)

Больше интересных практических приемов работы с тэгами вы найдете в приложении к документу VMware vSphere 6.7 Tagging Best Practices.

Некоторые пользователи виртуальной инфраструктуры VMware vSphere после недавнего обновления браузера Google Chrome (а недавно вышел Chrome 80) заметили, что через vSphere Client 6.7 больше не получается подключиться:

В консоли браузера Chrome можно увидеть вот такую ошибку:

Error in connection establishment: net:: ERR_CERT_AUTHORITY_INVALID

Проблему эту подсветили наши коллеги с Reddit. Связана она с тем, что новый Chrome 80 имеет повышенные требования к безопасности и требует повторной генерации и установки сертификата с хоста ESXi. Решается проблема, как отметили в комментариях, следующим образом:

1. Идем на хост ESXi, открываем Networking -> TCP/IP stacks -> Default TCP/IP stack по ссылке: 

https://<current-hostname>/ui/#/host/networking/netstacks/defaultTcpipStack

2. Изменяем настройки хоста.

Устанавливаем Host-name (например: esx1) и Domain-name (например: my.local) и сохраняем файл.

3. Идем по ssh на хост ESXi и выполняем там следующие команды:

cd /etc/vmware/ssl
/sbin/generate-certificates

Копируем файл castore.pem на клиентский комьютер и устанавливаем его в раздел "Trusted Root Certification Authorities". Для Windows переименовываем файл castore.pem в castore.pem.cer и просто устанавливаем его двойным кликом. Выбираем Local Machine->Manual->Browse->выбираем Trusted Root Certification Authorities.

4. Перезапускаем службу хоста ESXi:

/etc/init.d/hostd restart

После этого vSphere Client через Chrome 80 должен работать без проблем.

На днях компания VMware сделала анонс о грядущих изменениях в лицензировании платформы виртуализации VMware vSphere. Теперь понятие "лицензия на CPU" будет включать в себя процессоры, которые содержат до 32 физических ядер.

Если в процессоре больше ядер, то квантоваться они будут по 32 штуки - то есть, если в физическом CPU 64 ядра, то вам потребуется 2 лицензии VMware vSphere (2x32). Надо понимать, что речь идет о физических ядрах процессоров, а не о логических, доступных через Hyper-threading.

Процессоры с таким количеством ядер уже не за горами - например, AMD анонсировала процессор Ryzen 9 3990X с 64 ядрами, который будет стоить $4 000 (его обещают выпустить уже 7 февраля). Intel уже продает процессор Xeon Platinum 8280 с 28 ядрами на борту, но скоро в соревновании с AMD неизбежно надо будет делать больше ядер - так что изменения в лицензировании vSphere уже скоро станут вполне актуальны.

Наглядно новую схему лицензирования процессоров можно представить так:

Данные изменения вступят в силу 2 апреля 2020 года, но до 30 апреля действует grace period - то есть до этой даты вы сможете купить и лицензировать хосты VMware ESXi по старым правилам (очевидно, что VMware потребует доказательства приобретения и самих серверов до этой даты). Поэтому если до этого времени вдруг у ваших процессоров окажется очень много ядер - самое время будет приобрести лицензии VMware vSphere впрок.

На днях компания Intel опубликовала руководство по безопасности Security Advisory INTEL-SA-00329, в котором описаны новые обнаруженные уязвимости в CPU, названные L1D Eviction Sampling (она же "CacheOut") и Vector Register Sampling. Прежде всего, надо отметить, что обе этих уязвимости свежие, а значит исправления для них пока не выпущено.

Соответственно, VMware также не может выпустить апдейт, пока нет обновления микрокода CPU от Intel. Когда Intel сделает это, VMware сразу выпустит патч, накатив который на VMware vSphere вы избавитесь от этих потенциальных уязвимостей.

Основная позиция VMware по вопросу этих уязвимостей приведена в статье KB 76949 - VMware response to Vector Register Sampling (CVE-2020-0548) and L1D Eviction Sampling (CVE-2020-0549) speculation execution vulnerabilities in Intel processors. Соответственно, первым делом надо подписаться на обновление этой статьи (также неплохо бы подписаться на список рассылки VMware Security Advisory).

Давайте посмотрим, что это за уязвимости:

• Vector Register Sampling (CVE-2020-0548). Эта уязвимость является пережитком бага, найденного в подсистеме безопасности в ноябре прошлого года. Она связана с атаками типа side-channel, о которых мы писали вот тут. В рамках данной атаки можно использовать механизм Transactional Synchronization Extensions (TSX), представленный в процессорах Cascade Lake. О прошлой подобной уязвимости можно почитать вот тут. А список подверженных уязвимости процессоров Intel можно найти тут.
• L1D Eviction Sampling (CVE-2020-0549). Эта уязвимость (ее также называют CacheOut) позволяет злоумышленнику, имеющему доступ к гостевой ОС, получить доступ к данным из памяти других виртуальных машин. Более подробно об уязвимостях данного типа можно почитать на специальном веб-сайте. Также вот тут находится список уязвимых процессоров.

Следите за обновлениями VMware, патчи будут доступны сразу, как только Intel обновит микрокод процессоров. Достаточно будет просто накатить обновления vSphere - и они пофиксят уязвимости CPU.

На сайте проекта VMware Labs появилась новая версия мобильного клиента для управления платформой VMware vSphereс мобильного телефона - vSphere Mobile Client 1.9.1 (а немногим ранее вышла версия 1.9). Напомним, что прошлая версия клиента vSphere Mobile Client 1.6 была выпущена в октябре прошлого года.

Давайте посмотрим, что нового появилось в мобильном клиенте за последнее время:

• Возможность сохранить информацию о доступе к vCenter Server (адрес сервера и имя пользователя).
• Возможность использовать распознавание FaceId или доступ по отпечатку пальца для логина на сервер vCenter.
• Добавлено быстрое действие выключения хоста ESXi.
• Улучшена совместимость с движком автозаполнения в полях ввода логина.
• Исправлены мелкие баги прошлых версий.

Скачать обновленный vSphere Mobile Client 1.9.1 можно по этим ссылкам:

• Android (доступно как Early access приложение).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.

Недавно компания Microsoft объявила о том, что мартовские обновления Windows в этом году затронут поведение серверов Microsoft LDAP (доменных контроллеров), которые являются частью сервисов Active Directory. Эти изменения заключаются в том, что теперь механизмы LDAP channel binding и LDAP signing будут включаться по умолчанию, а для уже существующих инсталляций дефолтные настройки изменятся. На это обратил внимание один из наших читателей, который дал ссылку на соответствующую статью коллег из компании VMware.

В целом, инициатива эта позитивная - она согласуется с оповещением безопасности CVE-2017-8563, которое говорит о том, что незащищенная коммуникация LDAP может быть скомпрометирована. Поэтому, начиная с марта, любая LDAP-коммуникация, которая не использует TLS, потенциально может быть отвергнута Windows-системой. Почитайте, кстати, об этой суете на Reddit.

Это, конечно же, затрагивает и платформу VMware vSphere, компоненты которой могут использовать как обычный протокол LDAP (ldap://), так и защищенный LDAPS (ldaps://) для соединения со службами Active Directory. Также VMware vSphere поддерживает и механизм аутентификации Integrated Windows Authentication (IWA), который не затрагивают грядущие изменения.

Если вы уже настроили ваш vCenter Server для доступа к Active Directory через LDAP с TLS (LDAPS) или через механизм IWA, то вам не стоит бояться обновлений (если эти соединения идут не через балансировщики или прокси-серверы).

Проверить текущую интеграцию с LDAP в vCenter можно в разделе Configuration -> Identity Sources:

Как мы видим из трех источников идентификации по ldap только один использует TLS и будет работать после апдейтов, а вот первые два источника требуют перенастройки.

После мартовских обновлений при логине в vSphere Client через аккаунты Active Directory вы можете получить вот такую ошибку:

Invalid Credentials

При попытке добавить или изменить Identity Source в vCenter вы получите вот такую ошибку:

Check the network settings to make sure you have network access to the identity source

Поэтому попытаться сделать нужные настройки (хотя бы в изолированной от производственного окружения среде) нужно уже сейчас. Тем более, что vCenter позволяет одновременно использовать несколько Identity Sources.

Для того, чтобы настроить и протестировать LDAP Channel Binding & Signing можно использовать следующие материалы:

• 2020 Microsoft LDAP channel binding and LDAP signing requirement for Windows
• ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing
• Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure
• How to enable LDAP signing in Windows Server 2008
• CVE-2017-8563 | Windows Elevation of Privilege Vulnerability

Документ о настройке LDAP Signing в Windows Server 2008 говорит, что вам надо изменить групповую политику "Default Domain Policy" (для домена), а также "Default Domain Controllers Policy" (для контроллеров домена), после чего дождаться ее обновления или обновить ее командой gpupdate /force.

Надо понимать, что обновление этих политик затронет не только инфраструктуру VMware vSphere, но и все остальные сервисы, использующие LDAP, поэтому процесс этот нужно тщательно спланировать. Кстати, если вы это будете делать для виртуальных машин с контроллерами домена в тестовой конфигурации, то можно сделать снапшот всего тестового окружения перед изменением конфигурации, чтобы откатиться к ним в случае, если вы что-то не предусмотрели (для производственной среды снапшоты контроллеров домена делать не стоит).

Чтобы проверить, что политики применились, можно использовать встроенную утилиту Windows ldp.exe. Запустите ее на контроллере домена и укажите адрес localhost и порт 389:

Дальше идите в меню Connection утилиты и выберите там пункт Bind, где нужно ввести креды доменного администратора и выбрать вариант Simple bind:

После этого вы должны увидеть ошибку "Error 0x2028 A more secure authentication method is required for this server", которая говорит о том, что вы корректно отключили все небезопасные байндинги LDAP:

Если вы не получили такой ошибки, то значит настройки у вас еще не применились, и их надо проверить.

О настройке сервера vCenter для LDAPS рассказано вот тут. Единственное, что вам потребуется - это добавить рутовый сертификат для сервера vCenter, который можно вывести следующей командой (если под Windows надо будет поставить Open SSL, под Linux утилита уже встроена):

echo | openssl s_client -showcerts -connect <FQDN>:636

Далее скопируйте все данные между "—–BEGIN CERTIFICATE—" и "—–END CERTIFICATE—–", после чего сохраните это в текстовый файл.

Никакой срочности до марта нет, поэтому не нужно суетиться и обновлять все Identity Sources, но разрабатывать план по переходу на LDAPS и тестировать его нужно уже сейчас. Будет неприятно, если пользователи неожиданно столкнутся с проблемой аутентификации. И да, откладывать обновления Windows не вариант - это единственный способ своевременно закрывать дырки в сфере информационной безопасности для вашей компании.

Хотя бы раз у каждого администратора VMware vSphere была такая проблема, когда один или несколько хостов VMware ESXi в консоли vSphere Client на сервере vCenter отображались в статусе Not Responding. Причин для этого может быть масса, сегодня мы постараемся разобрать наиболее частые из них.

1. Прежде всего, надо убедиться, что хост ESXi находится во включенном состоянии.

Желательно убедиться в этом как физически (сервер включен в стойке), так и взглянуть на его консоль (например, через iLO/iDRAC). Ситуация может быть такой, что хост выпал в PSOD (Purple Screen of Death, он же Purple Diagnostic Screen).

В этом случае с хостом надо разбираться в соответствии со статьей KB 1004250 и повторно добавлять его к серверу vCenter, когда он успешно загрузится.

2. Если хост ESXi включен, но все еще находится в статусе Not Responding, надо попробовать перезапустить там Management agents (операция Restart Management Network).

Они включают в себя сервисы по коммуникации между сервером vCenter и хостом ESXi. Делается это в соответствии со статьей KB 1003490.

Также будет не лишним выполнить тест сети управления - опция Test Management Network. Ошибки, возникающие при этом, помогут понять, что случилось:

3. Проверьте, что со стороны vCenter Server у вас есть соединение с хостом ESXi - как по IP, так и по FQDN.

Казалось бы очевидный шаг, который не все выполняют первым при первичной диагностике. Просто сделайте пинг хоста ESXi со стороны сервера vCenter:

4. Убедитесь, что со стороны сервера ESXi также виден сервер vCenter.

Дело в том, что vCenter ожидает регулярных хартбитов со стороны хостов ESXi, чтобы считать их подключенными. Если в течение 60 секунд он не получает таких хартбитов, то он объявляет хост ESXi Not Responding, а в конечном итоге и Disconnected.

Иногда такое состояние возникает, когда сервер vCenter спрятан за NAT относительно хостов ESXi:

В этом случае серверы ESXi не смогут достучаться до сервера vCenter. Более того, такая конфигурация вообще не поддерживается со стороны VMware (см. статью KB 1010652), несмотря на то, что для нее существует workaround.

Ваша задача - обеспечить коммуникацию хоста ESXi с сервером vCenter по порту 902 (TCP/UDP):

Проверить коммуникацию по порту 902 можно с помощью Telnet.

Также тут вам могут помочь следующие статьи базы знаний VMware:

• Verifying the vCenter Server Managed IP Address (1008030)  
• ESXi 5.0 hosts are marked as Not Responding 60 seconds after being added to vCenter Server (2020100)
• ESXi/ESX host disconnects from vCenter Server after adding or connecting it to the inventory (2040630) 
• ESX/ESXi host keeps disconnecting and reconnecting when heartbeats are not received by vCenter Server (1005757)

Кстати, таймаут в 60 секунд для хартбитов можно увеличить, например, до 120 секунд, если у вас большие задержки в сети. Для этого нужно изменить значение параметра config.vpxd.heartbeat.notrespondingtimeout в расширенных настройках сервера vCenter, как описано в статье KB 1005757.

5. Попробуйте убрать хост ESXi из инвентори vCenter и добавить его снова.

Делается это в соответствии со статьей KB 1003480. Просто выберите для хост ESXi в контекстном меню vSphere Client опцию Disconnect:

Потом просто добавьте хост ESXi в окружение vCenter снова.

6. Если ничего из этого не помогло - время заглянуть в логи.

В первую очередь надо посмотреть в лог агента vpxa (/var/log/vpxa.log), как описано в статье KB 1006128. Например, причиной того, что агент vpxa не стартует может оказаться нехватка памяти, выделенной для сервисов ESXi. Тогда в логе vpxa будет что-то вроде этого:

[2007-07-28 17:57:25.416 'Memory checker' 5458864 error] Current value 143700 exceeds hard limit 128000. Shutting down process.
[2007-07-28 17:57:25.420 'Memory checker' 3076453280 info] Resource checker stopped.

Также нужно убедиться, что процесс hostd работает и отвечает на команды. Для этого можно заглянуть в лог hostd (/var/log/vmware/hostd.log), как описано в KB 1002849. Например, там может быть вот такая ошибка:

2014-06-27T19:57:41.000Z [282DFB70 info 'Vimsvc.ha-eventmgr'] Event 8002 : Issue detected on sg-pgh-srv2-esx10.sg-pgh.idealcloud.local in ha-datacenter: hostd detected to be non-responsive

Ошибки могут вызывать разные причины, но наиболее частая из них - нехватка ресурсов для сервиса hostd.

7. Последнее, но не менее важное - проверить, нет ли проблем с хранилищем.

Если все остальное уже посмотрели, то нужно обязательно отработать вариант с неполадками хранилища на хосте ESXi. Основные рекомендации по этому случаю даны в KB 1003659. Диаграмма траблшутинга в этом случае выглядит следующим образом (кликабельно):

Вывод

Если ваш хост ESXi перешел в статус Not Responding или Disconnected, попробуйте сначала такие простые действия, как проверка включенности самого ESXi, пинг хостов vCenter и ESXi в обе стороны (не забыв также порт 902), рестарт Management agents, передобавление хоста ESXi в инвентори. Потом посмотрите более сложные варианты, такие как работоспособность агента vpxa и сервиса hostd. Ну а потом уже проверяйте работу хранилищ на ESXi, где может быть много всякого рода проблем.

В конце ноября прошлого года мы писали о постерах, посвященных решению vRealize Network Insight и его очень широким возможностям поиска. Эти возможности позволяют находить нужные сущности и объекты в инфраструктуре VMware vSphere, NSX и прочих компонентах.

Вышедший в начале января постер vRealize Network Insight Search Poster for SD-WAN & VeloCloud показывает, какие поисковые шаблоны можно использовать для платформы SD-WAN (это технология купленной компании VeloCloud, которая реализует концепцию Software-Defined Networking в рамках WAN-сетей). Как некоторые из вас помнят, интеграция с решениями VeloCloud появилась в vRNI пятой версии.

Собственно, сам постер:

Второй интересный постер - это vRealize Network Insight Search Poster for Kubernetes. Он позволит вам найти объекты нативной инфраструктуры Kubernetes или развернутой на платформах VMware PKS или OpenShift.

Итого все постеры по функциям поиска в решении vRNI вы можете скачать по этим ссылкам:

• Kubernetes Search Poster
• SD-WAN & VeloCloud Search Poster
• NSX for vSphere Search Poster
• Network Flow Search Poster
• Virtual Machine Search Poster

На сайте проекта VMware Labs появилась действительно интересная новинка - утилита vSphere Software Asset Management (vSAM). С помощью vSAM можно собрать подробную информацию об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - весь инвентарь и доступные лицензии, проще говоря, ассеты.

Утилита забирает все данные по API и генерирует отчет об использовании лицензий виртуальной инфраструктуре в формате PDF, который могут использовать администраторы, менеджеры и консультанты для целей отчетности, планирования и любых других.

Сама утилита vSAM представляет собой легковесное Java-приложение, которое может работать под Windows, Linux или Mac OS. Давайте посмотрим на его возможности:

• Поддержка кластера хостов ESXi под управлением vCenter Server, а также отдельных серверов ESXi с версиями vSphere 5.5, 6.x или более новыми.
• Генерация комплексных отчетов в следующих категориях:
  • Высокоуровневая информация об инсталляции
  • Отчет о компонентах (отдельные ESXi или кластер серверов с vCenter)
  • Высокоуровневый отчет об использовании лицензионных ключей
• Генерация рекомендаций в следующих сферах:
  • Оповещение об использовании триальной лицензии
  • Срок лицензии:
    • Оповещение об истечении лицензии через 90 дней
    • Алерты об истекших лицензиях
  • Емкость доступных лицензий
    • Оповещение об использовании лицензий выше заданного порога
    • Оповещение о нехватке лицензий
    • Алерт о превышении лицензионных лимитов
  • Жизненный цикл продуктов
    • Информация по вступлении в фазу End of General Support info
    • Оповещение за 90 дней для EoGS
    • Нотификация о неподдерживаемых больше продуктах
  • Защита чувствительной информации за счет:
    • Сбор данных только для задачи Software Asset Management
    • Маскирование чувствительной информации в отчете
    • Поддержка шифрования файла с сырыми данными
  • Поддержка объединения нескольких отчетов в один
  • Поддержка английского и китайского языков
  • Поддержка кастомизации отчетов

Вот примеры сгенерированных отчетов:

Скачать утилиту VMware vSphere Software Asset Management Tool можно по этой ссылке.

Осенью прошлого года компания VMware выпустила VMware Cloud Foundation 3.9. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

На днях было выпущено небольшое обновление архитектуры VCF 3.9.1, где появилось несколько небольших новых возможностей.

Главное обновление - это новый Bill of Materials (BoM) для последних версий продуктов (включая апдейты 2020 года):

Остальные новые возможности включают в себя:

• Функция Application Virtual Networks (AVN) - она позволяет решению vRealize Suite быть развернутым в сетях NSX overlay networks. AVN, которые являются стандартом по умолчанию, начиная с этой версии архитектуры VCF, предоставляют преимущества портируемости и быстрого восстановления после запланированного простоя или в случае аварии. Чтобы узнать больше об этих сетях и перевести компоненты vRealize Suite на эту технологию почитайте вот эту статью.
• Поддержка API для нескольких физических сетевых адаптеров и распределенных коммутаторов (vSphere Distributed switches). Теперь API поддерживает до трех vDS и до 6 физических NIC, что дает возможность применения API в высокопроизводительных средах с большим числом адаптеров и виртуальных коммутаторов (например, физическое разделение типов трафика).
• Улучшения Cloud Builder - обновленный графический интерфейс включает в себя несколько улучшений рабочих процессов, а также показывает в отчетах детали задач, которые были выполнены во время развертывания.
• Улучшения Developer Center - теперь можно получить доступ к Cloud Foundation API и примерам кода из дэшборда SDDC Manager.

Более подробная информация об улучшениях VMware Cloud Foundation 3.9.1 приведена в Release Notes.

Больше двух лет назад мы писали о средстве DRS Dump Insight, появившемся на сайте проекта VMware Labs. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS.

Также мы писали о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).

На днях вышло обновление DRS Dump Insight 1.1, в котором появились следующие новые возможности:

• Пользователи теперь могут загружать несколько дампов, указав папку, в которой все они лежат.
• На базе загруженных дампов создается таймлайн миграций vMotion, по которому можно перемещаться в целях анализа нескольких дампов.
• Пользователи могут экспортировать результат анализа нескольких дампов в виде одного PDF-документа.
• Добавлена поддержка дампов VMware vSphere 6.5 Update 2, vSphere 6.5 Update 3 и vSphere 6.7 Update 3.
• Множество исправлений ошибок и улучшений движка анализа.

Воспользоваться утилитой DRS Dump Insight 1.1 можно по этой ссылке.

Интересное наблюдение от коллеги с блога ivobeerens.nl - оказывается драйверы pvscsi и vmxnet3, входящие в состав пакета VMware Tools, накатываются в гостевую ОС машин VMware vSphere через службу обновлений Windows Update:

В версии VMware Tools 10.3.10 (или выше) это работает для ОС Windows Server 2016 и Windows Server 2019.

Таким образом, указанные драйверы обновляются как часть процесса обновления Windows, что, в свою очередь, сокращает число требуемых перезагрузок во время обновлений.